Nebula 1/Nebula One.iso/Communications/IBTip/Source/tip3.man

Text File | 1995-06-12 | 8.8 KB | 187 lines

The program tip3 is a replacement for the tip that comes with the NeXT.  It
includes a facility for doing xmodem, ymodem, and zmodem transfers by executing
the programs /usr/local/bin/sz and /usr/local/bin/rz, which can be gotten from
the next listings on BIX.

In addition, tip3 will recognize the start of a zmodem download (by looking for
the beginning of the ZRQINIT sequence ^XB0) and automatically start the rz
process.  Thus, on BIX, one can give BIX the download command, and the download
of your SCRATCHPAD will happen automatically.

I wrote this utility primarily to communicate with BIX.  I also wanted to get
experience with Objective-C.  Tip3 was the first Objective-C program I wrote,
and has many things "hard-wired" that a truly friendly program would not.  For
example, the programs (rz, sz) used to accomplish the file transfers must exist
in the /usr/local/bin/ directory.  Also, the DELETE key is unconditionally
translated to backspace-space-backspace, so that the DELETE key will work
correctly on BIX.

I would most appreciate receiving any improvements made to tip3 (and I know
there is much room for improvement).

Installation of tip3 is like installation of other utilities, (simply copy it
into a directory in your PATH) except for one issue: the privilege of opening
the serial port.  One way to obtain this privilege is for tip3 to have its
setuid bit set and to be owned either by root or by the owner of /dev/cub (uucp
on my system).  The other way is to chmod the permission bits of /dev/cub so
that anyone can open it.

Following are usage notes:

SYNOPSIS
      tip3 [file]

DESCRIPTION

Tip3 manages a full-duplex connection to a device, typically a modem.
During operation, characters typed are sent to the device and characters
received from the device are written to the screen.

Invoking tip3 without an argument will open the /dev/cub (Port B)
device at 2400 bps.  With an argument tip3 will read and execute the
commands in the named file, a line at a time.  The set of commands
will be described below.  Most commands that can be executed from a
file can also be executed interactively by pressing ~ (tilde) followed
by a single character.  In the following table the corresponding tilde
sequence is given in parentheses before the command name.  Some
commands require more information, such as a file name or phone
number.  When invoked interactively, these commands will prompt the
user.  When invoked from a script file, the information must follow
the command as arguments.  For example, to set the receive protocol to
zmodem, one would interactively type ~p, answer the first prompt with
"r" (for receive) and specify "z" for the protocol.  In a script file,
one must write "protocol r z".  The commands are:

  (~^D) stop

    Quit the program.  This does not normally hang up the phone.  In many
    cases, the session can be restarted.

  (~p) protocol

    Set the file transfer protocols for sending or receiving files.  The
    program will prompt with
       Enter direction [(s)end,(r)eceive]:"
    for which protocol to set, and, after the user selects send or receive,
    with
      Enter desired send protocol [(x)modem,xmodem(1)k,(y)modem,(z)modem]:
    Once the choice has been made, both send and receive protocols will be
    displayed.

  (~^P) parity

    Set the parity to be sent to the remote host.  Some hosts require even or
    odd parity.  BIX and most BBS's don't need any specific parity.  This only
    affects the parity of characters sent to the host; the parity of incoming
    characters is ignored.  The program will prompt with
      Enter desired parity (even, odd, or none) [e,o,n]:
    and will display the choice, once it has been made.

  (~s) send

    Send a file to the host using the currently selected "send protocol".  The
    program will prompt for a file, and will check for its existence.  If the
    file does not exist, the program will keep prompting until a good filename
    is entered.  Responding with just a return will abort the send.

    After a valid file is established, the program will prompt for a command to
    send to the host.  This string (with the trailing "return") will be sent to
    the host just before calling sz to perform the file transfer.  Normally
    this will be the command that would normally be typed to cause the host to
    receive a file.  The purpose of doing this is to avoid the several second
    pause waiting for the host protocol program to time out.

    An example upload, to BIX, is transcripted here (with annotations added):
                                         --------comment---------------------
      Rf:                               | BIX's prompt (user presses ~s)     |
      Enter file to send:comment        | tip3 prompts for file (user enters |
                                        |   filename "comment")              |
      Enter command to send to host:up  | tip3 prompts for host command (user|
                                        |   enters "up", the BIX command to  |
                                        |   upload a file to the scratchpad  |
                                         ------------------------------------
      Sending comment, 8 blocks: Give your local XMODEM receive command now.
      Sector   8  1k
                                         ------------------------------------
                                        | The above is the output of sz, the |
                                        | program that does the file transfer|
                                        |                                    |
      File transfer process ended       | tip3 gets control back from sz and |
                                        |    is back in its normal mode      |
      Rf:                               | BIX's prompt, after successful send|
                                         ------------------------------------
  (~r) receive

    Receive a file from the host using the currently selected "receive
    protocol".  If the receive protocol does not automatically obtain the file
    name as part of the process, a file name will be prompted for.

    The command to cause the host to send the file should be typed in prior to
    executing the receive command of tip3.  This is in contrast to the "send"
    command.

  (~c) capture

    This toggles capture mode.  When capture mode is on, all characters sent
    from the host are captured in a file as well as being displayed on the
    screen.  Turning this on will prompt for a file name for capturing.  The
    default is "tip.record".

    If the given file already exists, then the current session is appended to
    it.  So it is safe to specify the same file over multiple sessions, or to
    put a "capture fixed_filename" into a script.

  (~h) hangup

    This will attempt to hang up the phone, first by dropping DTR, then by
    sending three tilde's (~~~), pausing, and issuing the Hayes command ATH0.
    This Hayes sequence is entirely hardwired.

  (~e) readscript

    This reads and executes a script file (the e is for execute).  The file
    name will be prompted for.  One script can call another.

  (~b) baudrate

    This allows the user to set the transmission speed of the serial port.  The
    supported speeds are, in bits per second: 300, 1200, 2400, 4800, 9600.

       echo

    This will write the arguments to the screen.  This might be useful for
    status messages.  Not very likely though.

       say

    This will send the arguments to the serial port, and thus either to the
    modem or the remote host if the modem is "online".

  (~d) dial

    This command will prompt for a phone number to dial.  It assumes, like the
    hangup command, that the modem accepts Hayes "AT" type commands, and
    generates Hayes "verbose" responses (CONNECT, CONNECT 1200, CONNECT 2400,
    NO CARRIER, BUSY, NO DIALTONE).  If the response from the modem is either
    NO CARRIER or BUSY, then tip3 will pause a few seconds and try to dial
    again.  If the response is one of the CONNECT ones, tip3 rings the
    terminal's bell.

    To stop the redialing, press the ESCape key while tip3 is waiting for one
    of the Hayes responses; tip3 will respond with "User aborted dialing" and
    resume normal operations.


BUGS

Too many things are hard-wired, like the hayes commands and responses, the
serial port to use (/dev/cub), the location and name of the zmodem program, the
initial protocols (xmodem 1k for sending, zmodem for receiving).

Also, tip3 does not prevent other programs from opening the serial device, the
way tip does.  It is possible to start one instance of tip3 while another is
running (say, from another Terminal).  In such cases the output from the modem
gets split between the active tip3's.  There is nothing to prevent different
users from running tip3 at the same time.  This really should be fixed, so I'll
have to figure out someday how it is done.